ソフトウェア開発プロジェクトにおけるよくある議論は、ソフトウェアの品質向上に時間を費やすか、より価値のある機能のリリースに集中するかのどちらかです。通常、機能を提供するというプレッシャーが議論を支配し、多くの開発者はアーキテクチャとコード品質に取り組む時間がないと不満を漏らします。この議論は、品質を向上させるとコストも増加するという、私たちの共通の経験に基づく仮定に基づいています。しかし、直感に反する現実は、内部ソフトウェアの品質を高めることで、新機能の開発を遅らせる不要な要素が排除され、ソフトウェアを拡張するコストが削減されるということです。

理想的な状態では、プロダクトモード組織は、明確に表現された、または表現されていないユーザーニーズに迅速に対応する、疎結合の自律的なチームで構成されます。しかし、時折、複数のチーム間の調整を必要とする対応が必要な機会が発生します。効果的に管理しないと、収益の損失、顧客の不満、チームの能力の浪費につながります。私たちは、これらの機会に対応する組織的な取り組みをプログラムと呼んでいます。この記事では、うまくいかなかったプログラムの例を通して、プロダクトモード組織におけるプログラム管理の経験を紹介します。

経営陣はメトリクスが大好きです。「私たちは、自分たちの状況を測定するための数値が必要です。数値は人々に焦点を当て、成功を測るのに役立ちます。」という考え方です。善意からではありますが、数値による管理は、直感に反して問題のある行動につながり、最終的にはより広範なプロジェクトや組織の目標を損ないます。メトリクスは本質的に悪いものではありません。ただ、多くの場合、不適切に使用されています。このエッセイでは、経営陣によるメトリクスの従来の使用方法によって引き起こされる多くの問題を示し、これらの機能不全に対処するための代替案を提供します。

インセプションとは、プロジェクトの開始時に行われる活動であり、関係者を一堂に集め、進行中の作業の共通の方向性と作業スタイルを設定することです。リーン・インセプションは、1週間で完了できる、集中的な形式のインセプションです。この期間中、私たちは製品の主要な機能と顧客を理解し、最小限の実行可能な製品の特性を策定するためのキャンバスを作成します。

アラインメントマップは、進行中の作業とビジネス成果の整合性を視覚化するのに役立つ、組織の情報ラジエーターです。作業は、通常の機能追加、または再構築、技術的負債の返済、ビルドおよびデプロイパイプラインの改善などの技術的な作業である可能性があります。チームメンバーは、アラインメントマップを使用して、日々の作業がどのビジネス成果の改善を目的としているかを理解します。ビジネスおよびITスポンサーは、それらを使用して、進行中の作業が関心のあるビジネス成果にどのように関連しているかを理解します。

私たちは、ソフトウェアプロセス、設計プラクティスなどについて、非常に多くの感情的な議論を目にします。ソフトウェア業界は、ソフトウェア開発の有効性の基本的な要素のいくつかを測定する能力がないため、これらの議論の多くは解決不可能です。特に、生産性を合理的に測定する方法がありません。

継続的フローは、多くの場合、アジャイルソフトウェア開発に関連付けられる、作業のスケジューリング方法です。チームは、ソフトウェアの機能をユーザーストーリーに分割します。次に、これらのストーリーに優先順位を付けて、大まかなリストを作成します。その後、チームはこれらのユーザーストーリーのいくつかを取り上げて作業し、1つが完了したら、リストから次のストーリーを取り上げます。

デザインスタミナ仮説では、デザインペイオフラインは、設計品質を市場投入までの時間とトレードオフできる機能の量の下限です。

技術的負債は非常に有用な概念ですが、それをどのように測定するのかという疑問が生じます。残念ながら、技術的負債は金銭的負債とは異なり、どの程度借金をしているかを判断するのは容易ではありません（ただし、最近、金銭的負債の種類の測定に問題があったようです）。

5ポンドの袋に10ポンドのゴミを入れることはできません

-- 試したことのある人なら誰でも

ケントと私が「Planning Extreme Programming」を書いたとき、私たちは計画の本質を理解してもらうために、この気まぐれな引用を含めました。

多くの人は、アジャイルプロジェクトで固定価格契約を結ぶことはできないと信じています。アジャイルプロセスの全体のポイントは未来を予測できないことなので、これは不合理な推測ではありません。しかし、これは固定価格のアジャイル契約を結ぶことができないという意味ではありません。これは実際には、固定スコープ契約を結ぶことができないという意味です。

多くの企業は、スコープと価格を固定する契約を結ぶという考え方を好みます。なぜなら、それがリスクを軽減すると考えているからです。この幻想は、彼らの金銭的義務が取引価格で固定されていると言っています。満足のいくソフトウェアを入手できなくても、費用はかかりません。

よくある質問は、大規模プロジェクトをアジャイル手法で実行できるかどうかです。結局のところ、多くのアジャイルアプローチは小規模プロジェクト向けに設計されており、彼らが抵抗する重量級のアイデアは、より大きなプロジェクトでより必要とされます。

最近のクライアントエンゲージメントでは、サーバーレスアーキテクチャが最適であると予測しました。しかし、サーバーレスアーキテクチャを採用するという考えは、ベンダーロックインの恐れから、クライアントにはうまくいきませんでした。小売業者にとって興味深い時期でした。AWSにとどまるということは、別の小売業であるAmazonに競争上の優位性が与えられる可能性があることを意味するからです。競合他社をサポートしないという考え方を踏まえ、クライアントは、私たちが選択したソリューションが他のクラウドベンダーに完全に移植可能であることを確認することに関心を持っていました。

ソフトウェアの良い点の1つは、人々がそれを望んでいて、すぐにそれを望んでいるように見えることです。組織がチームにソフトウェアの生産をスピードアップするように依頼するのは通常のことです。そして、時々、組織は、コミットメントを実際に示す方法で支援しようとします。それは、チームに人を増やすためにお金を使うことです。

私がアジャイルソフトウェア開発に初めて出会ったのは、エクストリームプログラミングの黎明期にケント・ベックと仕事をしたときでした。そのプロジェクトで私を感銘させたことの1つは、私たちが計画を進めた方法でした。これには、軽量でありながら、私が以前見てきたものよりも効果的な見積もり方法が含まれていました。10年以上が経過し、今では経験豊富なアジャイル主義者の間で、見積もりを行う価値があるのか、あるいは実際に有害なのかについて議論が交わされています。この質問に答えるには、見積もりがどのような目的で使用されるのかを検討する必要があると思います。

アジャイル開発の重要な特性は、機能の小さなサブセットでシステムを稼働させる方法を理解することです。私たちはビジネス上の価値を提供するためにソフトウェアを構築します。稼働が早ければ早いほど、少なくともそのビジネス上の価値の一部を早く得ることができます。

アジャイル開発の基本原則の1つは、要件の変更が単に予想されるだけでなく、歓迎されるということです。これは、Thoughtworksのような外部企業がクライアントのために作業を行う場合、特に課題となります。多くのクライアントは、固定スコープの幻想を抱いているため、固定価格での契約を望んでいます。しかし、固定スコープ契約はアジャイル開発とは全く相容れないものです。では、私たちのような企業はどうすればよいのでしょうか？

タイムボックス化されたイテレーションにおける一般的なアプローチは、関係するスタッフの稼働率を最大化するために、各イテレーションにできるだけ多くのユーザーストーリーを割り当てることです。スラックとは、ストーリーに割り当てられていない時間を意図的に残し、その時間 unplanned work に使用するという方針です。これは非効率に見えるかもしれませんが、通常はチームの生産性を大幅に向上させます。

最近、エクストリームプログラミングの計画アプローチを使用する複数のチームで、標準のストーリーポイントメカニズムを考案することに関するいくつかの質問を耳にしました。1つのチームにおける3つのストーリーポイントの工数と別のチームにおける3つのストーリーポイントの工数が同じになるように、複数のチームすべてが同等のストーリーポイントを使用することが期待されています。

私は、これを試みることはせいぜい価値が限られており、最悪の場合は危険だと考えています。

XPスタイルの計画を使用している場合、開発者から迅速な合意に基づく見積もりを取得する必要があります。見積もりを投げ込むことで、開発者が見積もりについて同様の見解を持っている場合（メモして先に進むことができます）と、意見の相違がある場合（ユーザーストーリーについてより詳細に話し合う必要がある場合）をすぐに判断できます。

タイムボックス化されたイテレーションは、プロジェクトの作業を分割してスケジュールする方法であり、特にアジャイルソフトウェアプロジェクトに関連付けられています。チームは、ソフトウェアの目に見える機能をユーザーストーリーに分割し、時間をイテレーションと呼ばれる固定期間（例：1週間）に分割します。次に、ストーリーをイテレーションに割り当てることで、ストーリーをスケジュールします。ストーリーは大まかに見積もられるため、チームは1つのイテレーションにいくつのストーリーが収まるかを把握できます。

ベロシティとは、大まかな工数の記述を経過時間に結び付けることで、計画を調整するのに役立つ概念です。ベロシティとは、チーム（または個人の場合は個人ベロシティ）が一定期間にどれだけの作業を完了するかを示すものです。昨日の天気の原則に従い、通常は過去の期間に完了した作業量を測定することで、ベロシティを決定する必要があります。典型的なアプローチは、過去3つの期間のベロシティを平均して、将来の期間のベロシティを決定することです。ベロシティはもともとエクストリームプログラミングの一部として形成されましたが、その後普及し、現在ではあらゆる種類のアジャイルソフトウェア開発で広く使用されています。

YAGNIはもともと「You Aren't Gonna Need It（あなたはそれを必要としないでしょう）」の頭文字です。エクストリームプログラミングのマントラであり、アジャイルソフトウェアチームで一般的に使用されることがよくあります。これは、将来ソフトウェアが必要になると推定される一部の機能は、「あなたはそれを必要としないでしょう」ため、今は構築すべきではないというステートメントです。

これは、今日完了する作業量は昨日完了した作業量と同じになるという原則です。反復型プロジェクトでは、今回のイテレーションでは前回のイテレーションと同じ量の作業を行うように計画する必要があるとされています。この用語は、エクストリームプログラミングコミュニティに由来します。